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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the signalHng transport related to RETAP signalHng to be used across the luant 
interface. The logical luant interface is a Node B internal interface between the implementation specific O&M function 
and the RET Antenna Control unit function of the Node B. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 25.460: "UTRAN luant Interface: General Aspects and Principles". 

[2] ISO/IEC 13239 (2nd Edition, March 2000): "Information Technology - Telecommunications and 

information exchange between systems - High-level data link control (HDLC) procedures". 

[3] 3GPP TS 25.461: "UTRAN luant Interface: Layer 1". 

[4] Antenna Interface Standards Group: "Control Interface for Antenna Line Devices". Standard 

No. AISGl 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Octet: 8 bits as used in [2] 

Device type: One octet identifying the type of a device 

Vendor code: A unique ASCII 2-character code assigned to each vendor in [4] 



3.2 


Symbols 




3.3 


Abbreviations 




For the purposes of the present document, the fol 


lowin 


ADDR 

ACK 

CRC 

DISC 

DM 

FCS 


Address 

Acknowledgment 
Cyclic Redundancy Check 
Disconnect (frame type) 
Disconnected Mode (frame 
Frame Checking Sequence 


type) 
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FRMR Frame Reject (frame type) 

HDLC High-Level Data Link Control 

I Information (frame type) 

INFO Information (field name) 

NAK Non Acknowledgment 

NRM Normal Response Mode 

RET Remote Electrical Tilting 

RNR Receive Not Ready (frame type) 

RR Receive Ready (frame type) 

SNRM Set Normal Response Mode (frame type) 

TWA Two Way Alternate 

UA Unnumbered Acknowledgement (frame type) 

UNC Unbalanced Operation Normal Response Mode Class 

XID Exchange ID (frame type) 

4 luant data link layer 

The Data Link Layer uses HDLC UNC 1,4,15.1 Class (see 6.10 in [2]) TWA according to [2]. 

4.1 Invalid receptions 

Frames shall be discarded if a framing error or data overrun occurs. 

4.2 Frame lengths 

HDLC frame lengths may vary between 4 and N octets. 

All secondary stations shall support an N of 78 octets. A secondary station may, after XID negotiation, support an N of 
not more than 65543 octets. 

4.3 Default address 

After reset, a secondary station shall use the no-station address (0x00). While it has the no-station address, it may only 
respond to device scan and address assignment messages. 

4.4 Windows size 

All stations shall support a window size of 1. A station may, after XID negotiation, support any window size up to 7. 

4.5 Message timing 

A minimum of 3 ms shall elapse between receiving and transmitting messages. 

A secondary station shall, after reception of a command with the P/F bit set, start transmitting a response within 10 ms 
from the time the final flag octet of that command frame was received. 

4.6 State model 

The connection state model for the layer 2 of the secondary station is shown in figure 4. 1 . The events written in italic 
are procedures from higher levels e.g. link establishment. The HDLC frames that correspond to the events are written in 
bold as command (from primary station) / response (from secondary station) messages. 
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Reset (any reset, power on, watchdog etc.) 
Link Timeout 



Link Disconnection 




Address 
Configuration 




(Address Assigned 




Link Establishment 



Figure 4.1 : Connection State IVIodel 



4.7 Device types 



Two device types are defined and identified by the assigned 1 -octet hexadecimal code. 

Table 4.1 : Device types and codes 



Device Type 


1 -octet hexadecimal code 


Single- Antenna RET Device 


0x01 


Multi-Antenna RET Device 


0x11 



4.8 XID negotiation 

XID negotiation shall use the standard format (see 5.5.3.1-5.5.3.2.3.2 in [2]). See Annex B for a brief description of 
XID negotiation and Annex C to E for examples of XID negotiations. All GL fields have a size of 1 octet. 

4.8.1 HDLC parameters 

Format Identifier (FI) shall be 0x81 and Group Identifier (GI) shall be 0x80. All secondary stations shall support the 
following parameters: 

Table 4.2: HDLC Parameters for secondary stations 



PI 


PL 


Description of PV 


5 


4 


Maximum information field length - transmit (bits) 


6 


4 


Maximum information field length - receive (bits) 


7 


1 


Window size - transmit (frames) 


8 


1 


Window size - receive (frames) 
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4.8.2 Protocol version 

Format Identifier (FI) shall be 0x81 and Group Identifier (GI) shall be OxFO. All secondary stations shall support the 
following parameter: 

Table 4.3: HDLC Parameter: protocol version 



PI 


PL 


Description of PV 


5 


1 


3GPP Release Id 



4.8.3 Addressing 

The primary station broadcasts the XID commands. The secondary station(s) which match shall respond. The primary 
shall ensure that only one secondary matches the supplied parameter(s). See below for details. 

Format Identifier (FI) shall be 0x81 and Group Identifier (GI) shall be OxFO. All secondary stations shall support the 
following parameters: 

Table 4.4: HDLC parameters for addressing 



PI 


PL 


Description of PV 


1 


1 to 19 


Unique ID 


2 


1 


HDLC Address 


3 


1 to 19 


Bit Mask (for Unique ID), indicates a device scan 


4 


1 


Device Type (see table 4.1) 


6 


2 


Vendor Code as given in [4] 



The XID message can be used to assign HDLC addresses or to scan for devices. If parameter 3 is present, the XID 
message is used for a device scan. If parameter 3 is not present, the XID message is used for an address assignment. 

An address assignment XID command shall contain at least PI=2 (HDLC Address) and may not contain PI=3 (Bit 
Mask). During an address assignment all secondary stations first assume a match and then carry out the following steps: 

If PI=1 (Unique ID) is supplied, the right most PL octets of the secondary station's Unique ID is compared to the 
Unique ID in the XID command. If they are different, the secondary station does not match, and the message is 
ignored. 

If PI=4 (Device Type) is supplied, the device type of the secondary station is compared to the device type in the 
XID command. If they are different, the secondary station does not match, and the message is ignored. 

If PI=6 (Vendor Code) is supplied, the vendor code of the secondary station is compared to the vendor code in 
the XID command. If they are different, the secondary station does not match, and the message is ignored. 

If the secondary station still matches after these steps, the secondary station sets its HDLC address to the address 
specified in PI=2 and responds with an XID response which contains PI=1 and PI=4. 

NOTE: Unlike the normal XID negotiation, in this XID negotiation, the XID response message returns a different 
set of parameters than the XID command message. 

A device scan XID command shall only contain PI=1 (Unique ID) and PI=3 (Bit Mask). PI=1 and PI=3 shall be of 
equal length L. The secondary station masks its Unique ID with the bit mask in the XID command, and compares the 
first L octets of the result with the L octets of the Unique ID supplied in the XID command. If they match, the 
secondary station transmits an XID response message with PI=1 (Unique ID), PI=2 (HDLC Address) and PI=4 (Device 
Type). 
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For the device scan comparison, the Unique ID of the secondary station shall be padded with spaces (character code 
0x20) to a length of 19 bytes. 

The device scan messages may be utilised by the primary to identify all secondary stations on an interface. 

4.9 Link establishment 

Once the secondary station has been assigned an HDLC address, the primary station initiates the link establishment by 
sending the SNRM command frame. The secondary station responds with an UA frame and enters the state Connected. 

4.10 Link timeout 

Whenever a secondary station receives an HDLC frame addressed to itself, i.e. not an all-station address (OxFF), it shall 
restart a 3 minute timer. If this 3 minute timer expires, the secondary station shall enter the state No Address. 
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Annex A ( informative): 
HDLC description 



HDLC is defined in [2]. This description only covers the aspects of HDLC which are used by this TS. 
The HDLC definition "UNC 1,4,15.1 Class TWA" can be broken down to: 

• UNC; 

o Unbalanced operation (master slave operation); 

o Normal response mode (sequence numbers used in data frames); 

o Class. 

• Option 1 means use of XID negotiation; 

• Option 4 means use of UI frames; 

• Option 15.1 means use of start/stop transmission with basic transparency; 

• Two Way Alternate is the HDLC term for half duplex. 



A.1 



Basic structure 



In unbalanced operation, there is one primary station (master) which controls the bus and a number of secondary 
stations (slaves) which only are allowed to transmit when the primary station gives them permission to do so. 

All messages are transmitted as frames with the layout show in table A.l: 

Table A.l : Format of an HDLC frame 



Flagl 
octet 


ADDR 
1 octet 


Control 
1 octet 


INFO 

N octets 


FCS 

2 octets 


Flag 
1 octet 


0x7E 


Secondary 
Station Address 


Control bits 


Variable length 


CRC 


0x7E 



HDLC frames begin and end with a Flag (0x7E) (see A.5 for details). 

The transmitting station calculates a Frame Check Sequence (CRC 16) on all octets which follow the starting flag but 
not including the FCS octets. The checksum is transmitted as FCS in little endian order and followed by the closing 
flag. 

The receiving station calculates the checksum on all octets between the flags. When it finds the closing flag, it compares 
the checksum to a OxFOBS. If it is a match, the HDLC frame is processed. 

The address field contains the HDLC address of the secondary station. If the primary station sents the message, it is 
called a command and the address field contains the address of the secondary station as destination. If the secondary 
station sents the message, it is called a response and the address field contains the address of the secondary station as 
source. Secondary stations cannot communicate directly to each other. 

The control field defines one of three frame types: 

• I frames contain data as well as a send and receive counter; 

• S frames contain a receive counter; 

• U frames contain unnumbered commands. 



£75/ 



3GPP TS 25.462 version 6.0.0 Release 6 



11 



ETSI TS 125 462 V6.0.0 (2004-09) 



The INFO field is only present in I frames and XID frames. The INFO field in an I frame contains the layer 7 payload. 



A.2 UNC commands 

According to 6.6.2.1 in [2] the following commands in shall be supported in UNC mode: 

Table A.2: Commands required by UNC 



Commands 
(Primary Station) 



Frame type I 



Frame type RR 



Frame type RNR 



Frame type SNRIVI 



Frame type DISC 



Responses 
(Secondary Station) 



Frame type I 



Frame type RR 



Frame type RNR 



Frame type UA 



Frame type DM 



Frame type FRMR 



A.2.1 Set Normal Response Mode (SNRM) 

This command is used to set the secondary station in connected mode and reset its sequence number variables. 

A.2.2 Disconnect (DISC) 

This command is used to terminate the connection. 

A.2. 3 Unnumbered Acknowledge (UA) 

This response is used to confirm that the secondary received and acted on an SNRM or DISC command. 

A.2. 4 Disconnected Mode (DM) 

This response is used to inform the primary station that the secondary is disconnected. 

A.2.5 Receiver Ready (RR) 

This command and response is used to inform the opposite station (primary or secondary) that the transmitting station 
has empty buffers, i.e. is ready to receive an I frame. This aspect is used for flow control. 

It also contains the sequence number of the next frame the transmitting station expects to see. This works both as an 
ACK and a NAK depending on the value. 

A.2.6 Receiver Not Ready (RNR) 

Just like RR, except it informs the opposite station that the transmitting station does not have empty buffers, i.e. that it is 
not ready to receive an I frame. This aspect is used for flow control. 

A.2.7 Information (I) 

This command and response is used to transfer a block of data together with its sequence number. The command also 
includes the sequence number of the next frame the transmitting station expects to see. This way, it works as an RR. 
Like RR, it enables transmission of I frames from the opposite side. 
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A.2.8 Frame Reject (FRMR) 

This response is used to indicate an error condition. The two most hkely error conditions are: 

• Invahd command; 

• Sequence number problem. 

The latter is used when the primary station has requested retransmission of a sequence number which it has already 
acknowledged. 

A.3 Option 1 

Option 1 means the addition of the XID command/response, which is used for parameter negotiation. 



A.4 Option 4 



Option 4 means the addition of the UI command/response, which is used to transfer information without changing the 
sequence numbers used by I frames. 



A.5 Option 15.1 



Option 15.1 means that the serial link is not synchronous and start/stop flags are used (asynchronous serial link). The 
flags are coded as 0x7E and basic transparency is used. 

This means that all octets between the flags are part of the frame and shall not be transmitted as 0x7E. Since the frame 
may contain 0x7E, basic transparency is used, which means that 0x7E is transmitted as 0x7D Ox5E and 0x7D is 
transmitted as 0x7D Ox5D. The receiving station converts back on reception. 

All checksum calculations are done on unconverted data. 

A. 6 Link safety 

HDLC provides the upper layer with a safe link between two stations. 

Unless excessive frame lengths are used, the CRC16 checksum provides excellent protection against transmission 
errors. At worst, 10"' of the bit errors will not be detected. The likelihood of an undetected error in a frame can be 
calculated by multiplying 10"' with the Bit Error Rate (at least 10"' for a reasonable link) and the frame length. 

The sequence numbers provide protection against: 

• Message duplication; 

• Message deletion; 

• Message re -ordering. 

Without sequence numbers, the protection is only given by a checksum and some sort of ACK. 

If the original message is lost, there will be no ACK and a timeout will cause retransmission which solves the problem. 

If the original message is not lost, but the ACK is lost, the same timeout will cause a retransmission which causes 
message duplication. 

With sequence numbers, the message is still retransmitted, but the receiving station sees that the sequence number is the 
same, i.e. that the message is a retransmission, and throws it away without processing it further. It does send an ACK 
which informs the transmitting station that the message got through. 

Without sequence numbers, commands such as "Increase by one" cannot be used, since there is no way to know how 
many times the command will be executed. 
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A. 7 Full duplex link 



The upper layer sees the HDLC link as a full duplex link, although the actual transmissions on layer 1 are half duplex. 
The reason for this is that the upper layer is not aware of any restrictions on transmissions or receptions between layer 2 
and layer 1 or between the stations. 

Whenever the upper layer wants to transmit, it places a message on the queue to layer 2. The message will not be 
transmitted until the primary station does a poll. Note, that this applies to both the primary and the secondary station. 

The same applies to reception. The upper layer will either be told by layer 2 when a message has arrived, or it will 
periodically check to see if a message has arrived at layer 2. Neither of these two methods will in any way influence the 
reception of a message. That only depends on when the primary does a poll. Note that this still applies to both the 
primary and the secondary station. 

A poll is a command frame from the primary station where the P/F (Poll/Final) bit in the control field is set to 1 . This 
informs the secondary that it is allowed to transmit response frames. 

U frames set the P/F bit, which means that they are polls. However, since the U frames used in UNC 1,4 require a 
specific U frame response, they are not used for I frame transmission, which is what the upper layer messages depend 
upon. 

An I, RR or RNR frame type with the P/F bit set constitutes a poll as used above. An RNR frame prevents transmission 
of I frames, so it does not really apply. 

Note, that whenever an I or RR poll occurs, the secondary station may transmit whatever I frame it wishes (as long as 
the window size is not exceeded, i.e. previous messages have been acknowledged). This means that the secondary 
station does not have to transmit a reply to a layer 7 instruction. It is free to transmit an alarm instruction, if an alarm 
has occurred. It is also free to transmit any valid reply to an earlier layer 7 instruction, if it has received (acknowledged) 
more than one. 
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Annex B (informative): 
HDLC parameter negotiation 

See also sections 5.5.3.1 -5.5.3.2.3.2 in [2]. 

Table B.1 : Format of XID parameters 



FI 


GI 


GL 


PI 


PL 


PV 


PI 


PL 


PV 



XID parameter negotiation uses a specific format (see table C.l) to transfer parameters. 

The parameters are identified by a one octet Format Identifier (FI) code and a one octet Group Identifier (GI) code. The 
Group Length (GL) is a one octet unsigned integer giving the length in octets of the parameters following it. 

The parameters are a sequence of PI/PL/PV values. The Parameter Identifier (PI) is a one octet code identifying the 
parameter. Parameter Length (PL) is a one octet unsigned integer giving the length in octets of the Parameter Value. 

The HDLC parameter negotiation is initiated by the primary station. The primary station transmits an XID frame with 
the values it suggests. The secondary station can either accept these or lower them. Regardless, it responds with an XID 
with the appropriate values. 

Generally this means that the primary initially uses whatever its maximum limit is for each parameter. If the secondary 
can accept this, it responds with the same values. If it cannot support that, it lowers the values. 

Maximum frame length is a good example. If the primary suggests using a frame length of 28000 octets, the secondary 
station can respond with 28000, if it can use that much or even more, of maybe 70 if that is its maximum supported 
frame length. 

The same applies to the Release ID. If a release 7 primary station attempts to communicate with a release 6 secondary 
station, the initial message will suggest release 7 and the response will be release 6. 

On the other hand, if a release 6 primary station attempts to communicate with a release 7 secondary station, the initial 
message will suggest release 6 and the response will release 6. 

Regardless, the primary station will have the final decision, since it can refuse to communicate with a station that does 
not support whatever parameter values it suggests. It can always repeat the XID negotiation with a new value. 



£75/ 



3GPP TS 25.462 version 6.0.0 Release 6 



15 



ETSI TS 125 462 V6.0.0 (2004-09) 



Annex C (informative): 

HDLC parameter negotiation example 

XID Frame from primary station: 

Table C.1 : XID Frame from Primary Station 



Field 


Content 


Description 


ADDR 


12 


Station address 


CTRL 


XID 


Command 


FI 


0x81 


Format identifier 


GI 


0x80 


HDLC Parameters set 


GL 


18 


Length of the parameter field (PI) 


PI 


5 


Maximum I Field length Transmit 


PL 


4 


Length of the PV field (octets) 


PV 


65543 


Maximum I Field length Transmit 


PI 


6 


Maximum I Field length Receive 


PL 


4 


Length of the octets value 


PV 


28000 


Maximum I Field length Receive 


PI 


7 


Maximum window size Transmit 


PL 


1 


Length of the PV field 


PV 


7 


Maximum window size Transmit 


PI 


8 


Maximum window size Receive 


PL 


1 


Length of the window size 


PV 


3 


Maximum window size Receive 



Response from secondary station: 

Table C - 2: XID Frame from Secondary Station 



Field 


Content 


Description 


ADDR 


12 


Station address 


CTRL 


XID 


Command 


FI 


0x81 


Format identifier 


GI 


0x80 


HDLC Parameters set 


GL 


16 


Length of the PI field 


PI 


5 


Maximum I field length Transmit 
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PL 


2 


Length of the PV field (octets) 


PV 


400 


Maximum I field length Transmit 


PI 


6 


Maximum I field length Receive 


PL 


4 


Length of the PV field (octets) 


PV 


65543 


Maximum I field length Receive 


PI 


7 


Maximum window size Transmit 


PL 


1 


Length of the PV field (octets) 


PV 


3 


Maximum I field length Transmit 


PI 


8 


Maximum window size Receive 


PL 


1 


Length of the PV field (octets) 


PV 


1 


Maximum window size Receive 
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Annex D (informative): 
Address assignment example 



D.1 Address Assignment command 

Table D.I : Format of the XID frame originated by the primary station 



Field 


Content 


Description 


ADDR 


OxFF 


All-station address 
(Broadcast) 


CTRL 


XID 


Command 


FI 


0x81 


Format identifier 


GI 


OxFO 


User defined parameter set 


GL 


n+14 


Length of parameter field 


PI 


1 


Parameter id 1 = Unique ID 


PL 


N 


Length of PV field in octets 


PV 


Unique ID 


Concatenation of vendor 
code and serial number (n 
octets) 


PI 


2 


Parameter id 2 = address 


PL 


1 


Length of PV field in octets 


PV 


1-254 


Assigned address 


PI 


3 


Parameter id 3 = 

Vendor Code as given in [4] 


PL 


2 


Length of PV field in octets 


PV 


Vendor Code 


Unique assigned vendor 
code as given in [4] 


PI 


4 


Parameter id 4 = 
Device Type 


PL 


1 


Length of PV field in octets 


PV 


Device Type 


Device Type as defined in 
table 4.1 


PI 


5 


Parameter id 5 = 
3GPP Release-ID 


PL 


1 


Length of PV field in octets 


PV 


Release-ID 


Latest supported 3GPP 
release version 
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D.2 Address assignment response 

The secondary station verifies the validity of the XID command. Thereafter the secondary station matches PVl, PV3 
and PV4. 

> To fulfil the match with the Unique ID given as the first parameter value PVl, the following two rules shall be 
valid: 

1 . Length of given Unique ID shall be less or equal to the length of its own Unique ID. 

2. When compared character by character, from right to left, they shall match. 

> To fulfil the match with the vendor code given as the third parameter value PV3, one of the following two 
rules shall be valid: 

1 . The given vendor code is a wild card coded as OxFF OxFF. 

2. The given vendor code matches exactly 

> To fulfil the match with the device type given as the fourth parameter value PV4, one of the following two 
rules shall be valid: 

1 . The given device type is a wild card coded as OxFF. 

2. The given device type matches exactly. 

Table D.2: Format of Address Assignment Response by the secondary station 



Field 


Content 


Description 


ADDR 


# 


Station address 


CTRL 


XID 


Command 


FI 


0x81 


Format identifier 


GI 


OxFO 


User defined parameter set 


GL 


n+14 


Length of parameter field 


PI 


1 


Parameter id 1 = Unique ID 


PL 


N 


Length of PV field in octets 


PV 


Unique ID 


Concatenation of vendor 
code and serial number (n 
octets) 


PI 


2 


Parameter id 2 = address 


PL 


1 


Length of PV field in octets 


PV 


1-254 


Assigned address 


PI 


3 


Parameter id 3 = 

Vendor Code as given in [4] 


PL 


2 


Length of PV field in octets 


PV 


Vendor Code 


Unique assigned vendor 
code as given in [4] 


PI 


4 


Parameter id 4 = 
Device Type 
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PL 


1 


Length of PV field in octets 


PV 


Device Type 


Device Type as defined in 
table 4.1 


PI 


5 


Parameter id 5 = 
3GPP Release-ID 


PL 


1 


Length of PV field in octets 


PV 


Release-ID 


Latest supported 3GPP 
Release version 



In case of a match it changes its address to the one supplied in the second PV. It then responds with an XID frame 
transmitted from its new address. 

If the match fails, the secondary station does nothing. 

After the assignment of its address a secondary station enters the state Connected. 

NOTE: Some further work on this example might be needed. 
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Annex E (informative): 
Device scan example 



In some situations it may be found that the Unique ID of a bus device is unknown or has been inaccurately recorded. 
This HDLC command exchange is used by the primary station to perform a binary tree scan of the bus, in order to 
identify all connected and disconnected devices, and is always carried out at 9.6 kbps. 

Table E.1 : Primary device scan command (XID Frame) 



ADDR 


OxFF 


All-station address 
(Broadcast) 


CTRL 


XID 


Command 


FI 


0x81 


Format identifier 


GI 


OxFO 


User defined parameter 

set 


GL 


2*n+4 


Length of parameter 
field 


PI 


1 


Parameter id 1 = Unique 
ID 


PL 


n 


Length of PV field in 

octets 


PV 


Unique ID 


Concatenation of vendor 
code and serial number 
(n octets) 


PI 


3 


Parameter id 3 = bit 
mask 


PL 


n 


Length of PV field in 
octets (same as for PI=1) 


PV 


bit mask 


Bit mask (n octets) 



> Device Scan Response 

When each secondary station receives the command it masks its Unique ID with the bit mask and compares the result 
with the Unique ID supplied. If they match, the secondary station responds using any unnumbered format frame 
according to table 8 of section 5.5 of [2]. It is recommended that the response of individual devices is subject to a 
random delay (within the permitted response time) to aid collision detection at the primary station. 

If there is no response, the primary station knows that no secondary station had those bits in its Unique ID, so the tree 
scan can be truncated at that branch. 

If multiple secondary stations respond, the messages may arrive after each other or at the same time. In the first case 
multiple responses will arrive before the timeout, in the second case the responses might garble each other, unless one 
secondary station is close enough to overpower the signal from the other(s). 

If any response arrives, a single frame, multiple frames or frames with incorrect checksums or framing errors, the 
primary station shall assume that that branch of the tree is inhabited and scan through it. 

NOTE: Some further work on the example given here is needed in order to align it with the device scan procedure 
described in section 4.8.3. 
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Annex F (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


September 
2004 


TSG- 
RAN#25 


RP-040345 


- 


- 


presentation to TSG-RAN for information 


- 


1.0.0 


September 
2004 


TSG- 
RAN#25 


RP-040345 


- 


- 


approved at TSG-RAN#25 and placed under change control 


1.0.0 


6.0.0 



















£75/ 



3GPP TS 25.462 version 6.0.0 Release 6 



22 



ETSI TS 125 462 V6.0.0 (2004-09) 



History 



Document history 


V6.0.0 


September 2004 


Publication 



























£75/ 



